Common standards for automatically switched OTN (G.709) networks include Automatically Switched Optical Networks (ASON) G.7715 and Generalized Multiprotocol Label Switching (GMPLS). These rely on link state routing protocols (e.g., Open Shortest Path First (OSPF)) and protocols such as Resource Reservation Protocol-Traffic Engineering (RSVP-TE) for circuit setup. Each node maintains the link state of the network and routes are computed at the source node based on least cost or some other criteria. Strict adherence to standards is required for interoperability between vendors. All of these run either over a dedicated in-band communication channel (e.g., General Communication Channel (GCC) in OTN) or out of band through a data communication network (DCN). Each node must maintain protocol stacks for the routing and signaling. A recent development in switching is SDN and an exemplary protocol is OpenFlow (www.openflow.org). OpenFlow targets packet technology such as Internet Protocol (IP) and Ethernet. OpenFlow separates a control plane and data plane and relies on a centralized controller to compute routes and program switches. OpenFlow and SDN provide some advantages over legacy switching such as rapid service introduction through customization, flexibility in how the network is used and operated, less reliance on lengthy standardization process for new innovations, open interfaces, etc.
OpenFlow programs match/action rules into switches. A match/action rule looks for a specific bit field in the packet/frame overhead and specifies an action upon match (forward, drop, and/or modify). Unknown packets are (by default) forwarded to the controller. Routing and rule provisioning is done by the controller. For example, OpenFlow with an SDN controller could replace traditional IEEE 802.1d Media Access Control (MAC) learning and forwarding. If a frame with an unknown destination address (DA) is received by a switch it is forwarded to the controller. The controller might determine a least cost path to the DA and then populate match/action forwarding rules into a forwarding database (FDB) on all of the network elements in the path. The network element needs no intelligence beyond matching the DA of the frame and forwarding to the port specified in the forwarding table. The above works well for packets but there is no obvious way to extend this to OTN. OTN (like SONET/SDH) requires a bit synchronous stream multiplexed on fixed time slots in a time division multiplexing (TDM) structure. OTN does not have the same lookup store and forward properties as packets, making it difficult to take full advantage of a protocol like OpenFlow. There are no solutions in the standards (or being proposed) for setting up connections with simple match/action rules for OTN as is done with Ethernet or other packet technologies. OTN efforts in the OpenFlow community are focused on porting the G.798 transport functional models to OpenFlow and creating the corresponding objects on the network elements. This approach is limited to using OpenFlow as a replacement for current provisioning interfaces and does not fully exploit OpenFlow's advantages mentioned herein.